1. Field of the Invention
The present invention relates to telecommunications services and more particularly to a method and system for sending messages in response to network activity.
2. Description of Related Art
Advances in telecommunications have enabled a number of special services to be made available to telecommunications subscribers. Examples of such services include abbreviated dialing, which allows a subscriber to reach a party by dialing less than the entire telephone number of that party, call forwarding, in which calls directed to the subscriber may be forwarded to another line, terminating call screening, which allows the subscriber to specify certain times during which incoming calls are to be rejected, and originating call screening, in which calls to certain telephone numbers are barred. In general, special telecommunications services (xe2x80x9cservicesxe2x80x9d) encompass those service features that do more than simply place or terminate telephone calls as dialed.
In the past, special telecommunications services were governed and provided for exclusively by the network switches or other entities that routed calls from one location to another. Such switches or other entities are usually at least part of a xe2x80x9cserving systemxe2x80x9d that provides service for a plurality of subscribers. A typical switch would include a database of control information and call processing logic in addition to its basic switching capabilities. In response to a call placed to or from a subscriber, the switch would then apply services defined by this call processing logic. For example, the service logic may indicate that all unanswered calls to a particular subscriber should be redirected to a particular voice mail server.
This approach was viewed as unwieldy, however, because a telecommunications provider needed to update the software and databases on all of its many switches in order to update services or add new services throughout its telecommunications network. And to further complicate matters, the software needed to program switches from different vendors often differed greatly.
To overcome these limitations, many telecommunications networks have now adopted an intelligent network (xe2x80x9cINxe2x80x9d) approach. According to the IN approach, much of the control information and call processing logic resides in a central network location or xe2x80x9ccentral control pointxe2x80x9d instead of in the multitude of switches. Each switch is then programmed with a relatively minimal set of service logic that causes the switch to query the central control point at predefined xe2x80x9ctrigger pointsxe2x80x9d during call processing, providing the central control point with parameters such as an identification of the calling and called parties, for example. When the central control point receives the query message, it may execute an appropriate set of service logic and/or consult appropriate databases in order to obtain information and instructions needed to provide a special service to the call. In turn, the central control point may return a response message to the switch, instructing the switch how to handle the call.
By applying the IN approach, the call processing information that is maintained locally for reference by the switch can be minimized, since most of the service logic and feature information for the subscriber can be maintained by the central control point instead. In this way, the telecommunications switches can be quite generic but still able to carry out a variety of services. Further, changes made to service logic at the central control point can apply to a large number of switches, which makes changing or activating services and adding new services much easier and reduces the problem of differences in switches from different vendors.
An IN network typically employs a standardized set of messages for communication between the switches (or other such entities) and the central control point, in order to allow for a variety of services. This standardized set of messages may be conveyed, for instance, over an out-of-band common channel interoffice signaling (CCIS) network, according to an established signaling protocol. The most well known such protocol is Signaling System #7 (xe2x80x9cSS7xe2x80x9d). According to SS7, predefined messages may be coded as Transaction Capabilities Application Part (xe2x80x9cTCAPxe2x80x9d) messages and routed via a signaling transfer points (xe2x80x9cSTPsxe2x80x9d) between the switches and the central control point.
The particular message set may vary depending on the type of network. For instance, traditional landline IN networks may operate according to standards embodied in Bellcore""s AIN Release 0.1 and AIN Release 0.2. Typical wireless networks, on the other hand, may operate according to other standards, such as Telecommunications Industry Association (TIA)/Electronics Industry Association (EIA) Interim Standard IS-41 (xe2x80x9cCellular Radiotelecommunications Intersystem Operationsxe2x80x9d) and Interim Standard IS-771 (xe2x80x9cWireless Intelligent Networkxe2x80x9d). The entirety of each of these standards (as well as all revisions thereof) is hereby incorporated herein by reference.
In general, the trigger points and other control information about call processing for a given subscriber or group of subscribers can be defined and recorded in a database that is maintained for reference by the serving system during call processing. This set of parameters is considered a type of profile for the subscriber, or a subscriber profile. When the switch receives a request to complete a call to or from a subscriber, the switch may consult the subscriber""s profile to determine whether it needs to query a central control point for call-handling instructions and/or whether it should carry out certain call processing logic itself.
A subscriber profile may define various types of trigger points and control information. At a basic level, for instance, a profile may define a so-called xe2x80x9call-digits trigger,xe2x80x9d which tells the serving system to query the central control point whenever the serving system receives a call origination attempt from the subscriber. Similarly, a profile may define a termination-attempt trigger, which tells the serving system to query the central control point whenever the serving system receives a request to connect a call to the subscriber. Such global triggers can be usefully employed to give the central control point extensive control over the services that will be provided to the subscriber. For example, upon receipt of a TCAP query that is generated upon call origination, the central control point may determine that the calling subscriber has subscribed to a pre-paid call accounting service; in response, the central control point may initiate logic that will time the subscriber""s call and decrement a pre-paid account balance accordingly.
The profile can define more specific triggers as well. For example, the profile may define a call origination trigger indicating that the serving system should further reference the subscriber profile to determine whether the subscriber is attempting to call a restricted destination, e.g., that the subscriber is blocked from calling a dialed number. Such a calling restriction may be desirable for group calling plans such as private branch exchange (xe2x80x9cPBXxe2x80x9d) or Centrex service, or for parental control, for instance. If the number is blocked, standard local service logic may direct the serving system to respond with a recorded message or other appropriate action, or the trigger may indicate that the serving system should query the central control point for guidance.
As still another example, the profile may define a call termination trigger that indicates that if the called subscriber""s line is busy or there is no answer, the call should be forwarded to a particular number that is recorded in subscriber""s profile. Alternatively, the termination trigger may indicate that, in response to a busy or no answer condition, the switch should query the central control point for processing instructions. In that event, the central control point may apply a set of service logic for the subscriber and decide that the call should be forwarded to a specified number (e.g., to a specified voice mail system), or that the switch should operate as normal (e.g., provide a busy signal). The central control point may then instruct the switch accordingly.
The IN concept has been applied in various types of telecommunications networks. Examples of such networks include, for instance, landline networks and wireless networks (e.g., cellular radio transmission networks).
In a traditional landline arrangement, each serving system comprises a switch referred to as a service switching point (xe2x80x9cSSPxe2x80x9d). The SSP is coupled via an STP network to a central control point, which is referred to as a service control point (xe2x80x9cSCPxe2x80x9d). The SSP maintains a subscriber profile database (e.g., a table, or more generally a data template or plurality of data templates), which defines trigger points for a given subscriber or group of subscribers. The SCP, in turn, maintains a subscriber profile database as well, indicating what service logic to provide for a particular subscriber or group of subscribers. When the SSP encounters a trigger point during call processing, it generates a TCAP query message defining the subscriber and other parameters, and it sends the query to the SCP. The SCP, in turn references its subscriber profile database, and identifies and executes the appropriate set of service logic. The SCP then generates and sends to the SSP a TCAP response message providing call handling instructions (e.g., a routing instruction, an instruction to play a message to the caller, or an instruction to simply connect the call to the dialed address.) Of course other arrangements are possible as well.
In traditional wireless networks, each serving system comprises a switch often referred to as a mobile switching center (xe2x80x9cMSCxe2x80x9d), as well as a subscriber profile database referred to as a visitor location register (xe2x80x9cVLRxe2x80x9d). A wireless subscriber station or mobile station (xe2x80x9cMSxe2x80x9d) may take the form of a cellular telephone, computer, pager, or personal data assistant (xe2x80x9cPDAxe2x80x9d), or other entity. The MS communicates over an air interface with a base station in a cell, and the base station is interconnected to the MSC, in order to provide connectivity with other points. Each mobile subscriber is registered in a home system. The home system includes a home location register (xe2x80x9cHLRxe2x80x9d) that defines the services and features authorized for use by the subscriber. When a mobile station roams into a given serving system (even its home system), the serving system engages in signaling communication with the HLR in the MS""s home system (i) to notify the HLR where the MS is located and (ii) to obtain the MS""s current profile. The serving system then stores the profile in its VLR for reference.
In wireless, the IN concept is also referred to as Wireless Intelligent Network (xe2x80x9cWINxe2x80x9d). Generally speaking, as in traditional landline systems, a wireless network may include a central control point to assist one or more serving systems in handling calls. However, a WIN arrangement typically employs a unique message set and provides additional capabilities in order to facilitate mobility management and other functions that are uniquely associated with providing service for mobile subscribers.
In current practice, the central control point in a WIN arrangement may be an SCP, HLR and/or other entity. When the serving system receives a call to or from a given MS, the serving system consults the MS""s profile in the VLR and determines whether to query the central control point. A trigger point in the profile may instruct the serving system to send a signaling message to one or another central control point. The signaling message is typically defined by industry standards and encapsulated in a TCAP message, and the message provides the central control point with appropriate parameters such as an identification of the MS. Upon receipt of the signaling message, the central control point may identify and execute a set of service logic for the MS and then generate and send to the serving system a response signaling message providing call handling instructions.
As an example, a serving system in a wireless network may include in the profile for a given MS an all-digits trigger that causes the serving system to query a designated SCP in response to any digit sequence dialed at the MS. If a subscriber then dials an abbreviated dialing extension, the serving system would query the designated SCP for call handling instructions, the SCP may then translate the extension into a full routing number and return the fill routing number to the serving system, and the serving system would route the call accordingly. As another example, the HLR for an MS may include in the profile for the MS a particular termination trigger that directs the serving system to query a designated SCP for call handling instructions in response to a termination attempt to the MS. When the serving system receives a termination to the MS, the serving system may then query the HLR for instructions, the HLR may send the termination trigger to the serving system as an xe2x80x9cadvanced termination triggerxe2x80x9d (i.e., one that does not normally reside in the serving system), and the serving system may respond to the trigger by querying the designated SCP for call handling instructions.
In addition, it is possible to arrange for the central control point in one system to communicate with the central control point in another system. For instance, one carrier""s network may include an SCP (SCP-1) that provides call processing logic for calls placed to or from the network. However, another carrier""s network may include an SCP (SCP-2) that contains service logic for a user who happens to be using the first carrier""s network at the moment. (For instance, the second carrier may sell telecommunications services to a customer of the first carrier). When SCP-1 receives a TCAP query from a serving system in the first""s carrier""s network, it may pass a signaling message to SCP-2 to find out what to do. SCP-2 may then identify and execute a set of service logic for the subscriber and then generate and return to SCP-1 a response signaling message providing call-handling instructions. SCP-1 would then send a response TCAP message to the serving system conveying the call-handling instructions, and the serving system would carry out the instructions. Such a mediated service logic system is disclosed, for instance, in the U.S. patent application entitled xe2x80x9cMethod and System for Providing Telecommunications Services Using Mediated Service Logic,xe2x80x9d which has been incorporated herein by reference.
In addition to providing enhanced services for processing traditional voice and data calls, advanced telecommunications systems have also given rise to other subscriber services. One such service offered in wireless communications systems is Short Message Service (xe2x80x9cSMSxe2x80x9d). SMS provides for the communication of short text messages to or from a mobile station or other entity without establishing a call connection. In general, the system may allow a person to simply type in a desired text message, indicate the directory number associated with a destination mobile station, and then transmit an SMS message encapsulating the desired text message. The telecommunications network then conveys the text message to the destination mobile station, where the message is typically displayed for receipt by an end-user.
A wireless network may provide a short message service center (xe2x80x9cSMSCxe2x80x9d) (sometimes also referred to simply as a message center (xe2x80x9cMCxe2x80x9d)), which is a functional entity that stores and forwards SMS messages. The store and forward function provides a method of sending short messages to their destination recipient or storing those messages if the recipient is unavailable to receive them. This store and forward function can generally be distinguished from the real-time delivery requirements of voice calls, although SMS messages may be delivered in real time.
According to industry standards, the message center can send messages to or from a functional entity known as a short message entity (xe2x80x9cSMExe2x80x9d). The SME is often an application entity that resides on a MS, and may sometimes be referred to as an MS-based SME. Alternatively, the SME can comprise, or reside on, another entity in a wireless or fixed network, i.e., in whether or not part of the wireless communications network. Typically, the SME can be arranged to compose, store, dispose of, act upon, display and/or otherwise manage short messages. It can also perform signaling functions to support other delivery features such as MS location and status queries, and mapping of destination addresses. In general, a typical SMSC can forward messages to an SME, store short messages for later delivery to an unavailable SMEs, apply originating and terminating SMS supplementary services (e.g., IN services) to short messages, and serve other functions.
Each MS-based SME is usually associated with an SMSC known as the xe2x80x9chome SMSCxe2x80x9d in the MS""s home system. The MS-based SME is qualified like an MS is qualified, with an HLR sending SME service profile information (origination and termination restrictions) to an SMS-capable serving system along with MS related profile parameters, so that the serving system can know that the MS is qualified to receive and/or send short messages. Typically, a given SMSC then maintains the mobile identification number (MIN) address information of the MSs that it serves, and the SMSC is addressable by the directory numbers (e.g., telephone numbers, IP addresses, e-mail addresses, etc.) of those MSs for mobile terminated messages. When the SMSC receives a message for one of its MSs, it may then identify the location of the MS and forward the message via the serving system to the MS.
As further background, FIGS. 1 and 2 illustrate some of the signaling involved in traditional SMS processing, as described, for instance, in Michael D. Gallagher and Randall A. Snyder, xe2x80x9cMobile Telecommunications Networking With IS-41xe2x80x9d (McGraw-Hill 1997). FIG. 1 first illustrates a scenario when one mobile station, MS-A (embodying SME-A), sends an SMS message to another mobile station, MS-B (embodying SME-B). As shown in FIG. 1, at step 1, MS-based SME-A first sends an air interface message, SMD-REQUEST (SMD-REQ), embodying a short message to its serving system. At step 2, the serving system routes the short message to SME-A""s SMSC (message center, xe2x80x9cMCxe2x80x9d), using an IS-41 SMSDeliveryPointToPoint Invoke (SMDPP) message. Such an SMDPP message may be routed using the same SS7signaling network as is used for routing other IS-41 messages (e.g., directing the message to a network point code associated with the SMSC), and/or using TCP/IP, X.25 or another desired protocol. The SMSC then returns an xe2x80x9csmdppxe2x80x9d acknowledgement message, and SME-A""s serving system returns an SMD-ACK to MS-A.
At step 3, SME-A""s message center might apply an originating supplementary service to the short message and then send an SMDPP message to the destination SME""s SMSC. At step 4, SME-B""s message center may apply a terminating supplementary service to the short message and then send an SMDPP message to SME-B""s serving system. At step 5, SME-B""s serving system then forwards the short message to the destination SME using the air interface SMD-REQ message, and SME-B responds with an acknowledgement SMD-ACK to signal acceptance of the SMD-REQ message.
An MS-based SME can be addressed by its host""s MIN (e.g., the MIN of the mobile station on which the SME resides). In order to then determine which SMSC to route a message to for a given destination SME, an entity can maintain a table of MIN-to-SMSC addresses (e.g., MIN to SS7 destination point code, or MIN to IP address, for instance), as is often done today in IS-41 networks for routing IS-41 messages to an MS""s HLR. Thus, for example, in FIG. 1, MS-A""s serving system can maintain a table that indicates the address of the SME-A""s SMSC for use in step 2, and SME-A""s SMSC can maintain a table indicating the address of SME-B""s SMSC for use in step 3.
Generally speaking, in order to terminate an SMS message to an MS-based SME, the SMSC that seeks to send the message must get a valid routing address for the system currently serving the SME. To facilitate this, IS-41 provides a special SMS_Address parameter that is conveyed to the HLR of an SMS-capable MS when the MS is registered in a new serving system. In addition, IS-41 provides an SMSRequest (SMSREQ) invoke message that can be used to request the current location of the MS-based SME.
FIG. 2 illustrates an exemplary set of processing functions that may be employed to register an MS-based SME (residing on MS-A) and to then terminate an SMS message to the SME. As shown in FIG. 2, when an SMS-capable MS is detected by a serving system, at step 1, the serving system sends a RegistrationNotification (REGNOT) invoke message to the MS""s HLR. If the serving system is SMS-capable, the message includes the SMS_Address parameter, which can be used to route short messages to the serving system for delivery to the MS-based SME. For instance, if the short message transport network is SS7-based, the SMS_Address parameter may contain an SS7 point code and subsystem number. (Alternatively, as another example, if the transport network is IP (internet protocol)-based, the SMS_Address parameter may contain an IP address.) When the serving system receives an SMDPP message addressed to this point code and subsystem number, it assumes the message is intended for a visiting MS-based SME that is specifically identified by address parameters in the SMDPP message.
In turn, when an SMSC seeks to send an SMS message to an MS-based SME, at step 2, it sends an SMSREQ message to the MS""s HLR. If the HLR has a valid SMS_Address for the SME, then, at step 3, the HLR returns the SMS_Address parameter in an SMSRequest return result (smsreq) message. At step 4, the SMSC then uses the SMS_Address to route the SMDPP message to the system currently serving the SME, and the serving system in turn sends the message to the SME identified in the SMDPP message, using an SMD-REQ message.
In some instances, an SME may be unavailable to receive SMS messages. This might occur, for instance, (i) if the SME (e.g., an MS-based SME) is not registered with an HLR, (ii) if the SME is registered on an SMS-incapable system, (iii) if the SME is for some reason not authorized for SMS service on the current serving system, or (iv) if the host MS is out of radio contact or intentionally inaccessible. When an SME is unavailable and the SME""s HLR receives a request for the SME""s SMS_Address with an SMSRequest message for instance, the HLR may indicate the unavailability to the querying SMSC, by returning an SMS_AccessDeniedReason parameter (e.g., denied, postponed or unavailable).
In an SMSRequest message, in addition to providing the destination MS""s MIN (and possibly its ESN), an SMSC can provide an SMS_NotificationIndicator parameter, which advises the HLR whether or not to notify the SMSC when the MS becomes available, in case the MS is currently unavailable. When an SMSC sends an SMSRequest message for an MS-based SME to the MS""s HLR and the MS is unavailable, the HLR may then store an indication that the SMSC has a message waiting for the MS, unless the SMS_NotificationIndicator parameter indicates that the HLR need not notify the SMSC when the MS becomes available. When the MS then becomes available, the HLR may send an SMSNotification message to the SMSC, providing the SMS_Address of the MS-based SME, and advising the SMSC that it may send the stored message to the SME.
As suggested above, SMS service can involve communication over various transport networks, such as conventional SS7 networks, IP networks (e.g., the Internet), and X.25 networks, for instance. In this regard, for example, an MSC or SMSC may be programmed as, or coupled with, an xe2x80x9cinterworking function,xe2x80x9d to convert SMS messages from an SS7-encapsulated form into a form appropriate for IP-transport. This may involve converting an SMS message into a stream of TCP/IP packets for transmission over the IP transport network. This arrangement may allow network access to external IP applications (i.e., SMEs) as well as inexpensive IP access between SMSCs belonging to different networks.
For instance, an SMS message generated in an SS7-based network can be conveyed over an IP network to a POP3 e-mail server, which can then convert the message into an Simple Mail Transfer Protocol (xe2x80x9cSMTPxe2x80x9d) e-mail message and forward the e-mail message to a designated email recipient (which may be considered a type of SME). As another example, text messages generated and conveyed in an IP network (e.g., by an e-mail client) might be conveyed via the interworking function to an SME in an SS7 network. An Internet Service Provider (ISP) may thus allow an Internet e-mail subscriber to send a text message to a designated MS-based SME referenced by a given directory number, for instance. As still another example, an SMSC or MSC in one carrier""s network might convey an SMS message, via an interworking function and an IP transport network, to an SMSC or MSC in another carrier""s network, and the other SMSC or MSC may then deliver the SMS message to a designated recipient.
The present invention stems initially from a realization that SMS messaging is generally external to call processing and other such network activity. For instance, when an originating SME (e.g., an MS or an e-mail client) sends an SMS message to a particular destination SME, the sender does not know whether the recipient is available. Similarly, when a originating MS initiates a voice or data call, the MS""s home SMSC system does not know that the call is being placed.
In accordance with a principal aspect of the present invention, these two distinct systems can be advantageously combined together, putting SMS functionality in the line of call processing. In particular, according to an exemplary embodiment, a network entity that is involved with processing calls can be arranged to recognize a call-processing event and then responsively invoke service logic to generate and send an SMS message to a particular destination.
As presently contemplated, the SMS message can describe some aspect of the call-processing event. For instance, assume that John Employee works for Paul Employer, and John Employee places a voice call to his friend Mary Smith on his landline telephone at work. An entity that is involved with processing that call can responsively generate and send an SMS message to Paul Employer""s mobile telephone, indicating that xe2x80x9cJohn Employee just called Mary Smith from his work phone.xe2x80x9d The entity might do so, for instance, by retrieving a canned message that reads xe2x80x9c_just called _xe2x80x9d, converting John and Mary""s telephone numbers into name-strings (e.g., by reference to an external database), and then filling in the blanks in the canned message. Alternatively, the SMS message can convey some other sorts of information, such as an advertisement, a reminder, a warning, or the like.
In accordance with another aspect, the call-processing entity can take various forms. For instance, it could be a central control point that normally serves to provide call-processing guidance to a serving system. Or it could be a serving system, such as a switch, that normally serves to connect calls for a subscriber. Still alternatively, it could be a service node or intelligent peripheral that normally serves as a platform to provide enhanced subscriber services for a switch or other such entity. Other examples exist as well.
Further, in accordance with alternative embodiments, the invention can involve automatically sending other types of informational messages in response to various types of network activity. For example, in response to a particular network event such as call origination or termination, for instance, a call-processing entity may invoke logic to cause an audio or video server to send a real-time media stream to a mobile station directory number, or to a designated Internet address or other destination. As another example, in response to the transmission of an SMS message (i.e., a type of network activity), a network entity may generate a fax transmission (e.g., via the well known ITU-T T.38 fax over IP protocol) that includes text indicating that the SMS message was just transmitted. The network entity may then transmit the informational fax message to a predefined destination. Many other examples are possible as well.
Thus, according to one aspect, the present invention may take the form of a messaging method by which a call-processing entity notes a predefined call-processing event and, responsive to the predefined call-processing event, the call-processing entity invokes logic (i) to generate an informational message that contains information about the call-processing event and (ii) to send the informational message to a message-destination. Alternatively, the invention may take the form of an apparatus or machine for carrying out these or other such functions.
According to another aspect, the present invention may comprise an improvement in a telecommunications network. The telecommunications network may comprise a serving system and a call-processing entity. The serving system may be arranged to serve a plurality of subscriber stations and, in response to a call-processing event associated with a subscriber station, the serving system may send a signaling message to the call-processing entity, defining information about the call-processing event. When the call-processing entity receives the signaling message, it responsively consults service logic associated with the subscriber station. As presently contemplated, in accordance with the service logic, the call-processing entity may then generate an informational message and send the informational message to at least one destination, such as a mobile station, for instance.
According to another aspect, the informational message can be a text message, an SMS message, a real-time media message such as audio (e.g., speech) or video, a fax message, an e-mail message, or another type of message. Further, the informational message can but need not necessarily include information about the underlying call-processing event, such as a description of the event for instance.
According to a further aspect, the call-processing event can be an origination event, a termination event, an off-hook event, a feature-invocation event, an event concerning a network condition such as congestion or other such activity, a threshold event such as a call-activity threshold event, or another event. For example, an origination event might be an attempt to originate a call, a termination event might be an attempt to terminate a call, and a call-activity threshold event might be a threshold number of calls placed. Other examples are possible as well.
According to another aspect, the function of generating an SMS message can comprise combining a predefined text message with a portion of the information defined by the signaling message, in order to establish a customized text message that includes information about the call-processing event. The SMS message might then comprise the customized text message. In other words, this may involve recalling an at least partially predefined message from a data storage medium, possibly modifying the message, and encapsulating the message as a payload in a text message. Further, this function can include translating some or all of the portion of information from a first type of information into a second type of information before combining the predefined text message with the portion of information. The translation may be from subscriber name to subscriber number, or vice versa, or may take other forms.
According to another aspect, the function of sending the SMS message to a destination comprises sending the SMS message via at least one intermediate entity to the destination. The intermediate entity can be, for instance, a mobile switching center (MSC), a bulk messaging gateway, or a short message service center (SMSC).
Further, according to another aspect, the call-processing event can relate to activity in one network domain (e.g., one network or sub-network), while the destination to which the SMS message is sent can comprise a network address in another network domain. For instance, the call-processing event can relate to a mobile station and the message destination can be a landline station, or the call-processing event can occur in a circuit-switched network and the SMS message can be sent via a packet switched network.
According to still another aspect, the function of generating the SMS message can comprise invoking an application on another entity to generate the SMS message or to obtain guidance about generating the SMS message, and the function of sending the SMS message comprises invoking an application on another entity to send the SMS message or to obtain guidance about sending the SMS message.